AWS再入門ブログリレー2022 AWS Global Accelerator 編

弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の 19日目のエントリ『AWS Global Accelerator 編』です。

AWS再入門2022

#AWS Global Accelerator

#AWS

大前諒祐

2022.03.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。

当エントリは弊社コンサルティング部による『AWS再入門ブログリレー2022』の 19 日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。19日目のテーマは『AWS Global Accelerator』です。

AWS Global Accelerator とは

概要

AWS Global Accelerator（以下 Global Accelerator）は re:Invent 2018 でリリースされたサービスで、Amazon CloudFront（以下 CloudFront）等と同様に、AWS のグローバルネットワークを使用したサービスとなっています。

特徴

Global Accelerator の主な特徴としては以下があげられます。

通信レイテンシーの改善
静的 IP によるアプリケーションへの単一エントリの提供
アプリケーションの保護

通信レイテンシーの改善

Global Accelerator の大きな特徴の一つが、ユーザーとアプリケーション間のネットワークレイテンシーの改善です。

通常、ユーザーがインターネット経由でアプリケーションにアクセスする場合は複数のネットワークを経由するため、各ネットワークの混雑状況などの影響を受けてレイテンシーの増加やデータ損失などが発生することがあります。

（画像引用 : AWS Global Accelerator）

一方で Global Accelerator を利用した場合、通信はユーザーになるべく近い場所（エッジロケーション）で AWS ネットワークに入ります。これにより、複数のネットワークを経由することによる悪影響の緩和や、AWS ネットワーク内のパフォーマンスの恩恵を受けられるため、結果としてレイテンシーの改善が見込めるケースが多くなります。

（画像引用 : AWS Global Accelerator）

実際の現場で Global Accelerator の導入を検討する際には「実際どのくらい早くなるの？」という観点はほぼ必ず出るかと思いますが、公式がインターネット経由と Global Accelerator 経由でのパフォーマンスの比較ツールを提供していますので、一つの参考情報として利用することが可能です。詳細は割愛しますが、弊社メンバーがブログを書いていたりしますので、良ければ参照ください。

レイテンシー改善という特徴を活かし、公式ドキュメントでは ゲームやリアルタイム通信を行うサービスに対して Global Accelerator を利用する ユースケースも紹介されていたりします。

AWS Global Accelerator と Amazon GameLift FleetIQ を活用してプレーヤーエクスペリエンスを向上させる | Amazon Web Services ブログ

同じく AWS グローバルネットワークを使用したサービスである CloudFront も上述の特徴を持つ形になりますが、Global Accelerator との使い分けについては後述します。

静的 IP によるアプリケーションへの単一エントリの提供

Global Accelerator には 静的な IP アドレス（anycast）が 2つ提供 され、クライアントはこの IP アドレスを利用してアプリケーションにアクセスすることができます。

これは、例えばアプリケーションをマルチリージョンに展開していてエンドポイントが複数ある場合などに有効です。各エンドポイントをオリジンとして Global Accelerator を使用することにより、クライアント側は複数のエンドポイントを意識することなく、提供される静的 IP アドレスを利用してアクセス することができる様になります。

（画像引用 : AWS Global Accelerator）

また、上記により Global Accelerator の背後に複数のオリジンを配置することができるため、エンドポイントのフェイルオーバーやスケーリング、A/B テストや B/G デプロイ等を行うことも可能です。後述しますが、各エンドポイントに対して重みづけを行い、送信されるトラフィックの量を調整する事も可能です。

アプリケーションの保護

Global Accelerator を利用することで、オリジンとなる ALB や EC2 に対してパブリックなインターネットからのアクセスを防ぐことができるため、アプリケーションに対する攻撃リスクを低減することができます。

Global Accelerator を利用する際、各オリジンに対してどの様なネットワーク構成にするのがセキュアかについては以下ブログにまとめられていますので、一読していただければと思います。

また、Global Accelerator はデフォルトで AWS Shield Standard の保護対象となっているため、一般的な DDoS 攻撃からアプリケーションを保護することにも役立ちます。

参考 : AWS Shield に AWS Global Accelerator の高度な DDoS 保護を追加

一方で、現時点（2022/3）で AWS WAF は Global Accelerator に対応していません。そのため、AWS WAF を利用したい際には ALB をオリジンとし、ALB に対して AWS WAF を適用いただく必要があります。

Global Accelerator の要素

ここでは、Global Accelerator を構成する要素や用語について記載していきます。

参考 : AWS Global Accelerator components - AWS Global Accelerator

アクセラレータ

アクセラレータ は Global Accelerator における一番大きなリソースの単位 となります。アクセラレータを作成し、それに対して後述するリスナーやエンドポイント等の設定を行い利用する形となります。

また、アクセラレータには 標準アクセラレータ と カスタムルーティングアクセラレータ の 2種類が存在し、コンソールでアクセラレータを作成する際にはアクセラレータのタイプを選択する事を求められます。

カスタムルーティングアクセラレータは、例えばゲームのマッチングなど、一つの EC2 に対して複数のユーザを割り当てたい場合など に利用できます。標準アクセラレータはトラフィックの負荷分散を目的として設計されているため、上記の様に任意のユーザを意図したターゲットにルーティングさせたいといった要件を満たせない場合があります。そういった場合は、カスタムルーティングアクセラレータの利用を検討するのが良いかと思います。

詳細については以下公式ブログやドキュメントを参照ください。カスタムルーティングアクセラレータではエンドポイントとして EC2 しか指定できない、等の制約もあるため利用前に一読いただく事を推奨します。

参考 : カスタムルーティングアクセラレータのガイドラインと制約事項 - AWS Global Accelerator

参考 : AWS Global Acceleratorのカスタムルーティングアクセラレータのご紹介 | Amazon Web Services ブログ

本エントリでは、以降 標準アクセラレータのみを考慮 した記載となりますので、ご留意ください。

リスナー

リスナー を定義する事で、作成した アクセラレータがクライアントからどの様な通信を受け付けるかを定義 することができます。具体的には、ポートとプロトコルのセットを指定してリスナーの定義を作成していく形になります。（厳密にはクライアントアフィニティの設定もありますが、これは後ほど解説します）

ひとつのリスナーに対して複数のポートを定義する事もできますし、ひとつのアクセラレータ内に 複数のリスナーを定義することも可能 ですので、要件に応じた柔軟な設定が可能となっています。下記の画像ではリスナーを 2つ定義しており、ひとつは TCP/80、もうひとつは TCP/81〜90 といった設定をしています。これにより、このアクセラレータは TCP/80〜90 の通信を受けられる様な形になりました。

リスナーを複数定義したとしても、クライアントはアクセラレータのエンドポイントに対して通信を行うため、リスナーの定義を意識する必要はありません。アクセラレータに対して通信を行うと、アクセラレータ側で定義済みのリスナーに基づいて後続処理を進めてくれます。

エンドポイント/エンドポイントグループ

エンドポイント は Global Accelerator が最終的にリクエストをルーティングするターゲットで、Global Accelerator では NLB/ALB/EC2/EIP が指定可能となっています。また、エンドポイントグループ は 1つ以上のエンドポイントが含まれるエンドポイントの集合体を指します。

標準アクセラレータの場合、各リスナーに対してそれぞれ 1つ以上のエンドポイントグループを指定する形になります。リスナーは、エンドポイントの正常性やトラフィックダイヤルによって設定されたトラフィック量に基づいて、それぞれのエンドポイントグループ/エンドポイントにトラフィックをルーティングします。（ヘルスチェックの仕組みやトラフィックダイヤルについては後述します）

エンドポイントグループ内の各エンドポイントは同じリージョンで構成する必要がありますが、リージョンが異なるエンドポイントグループをひとつのリスナーに関連づけることができます。（ひとつのリスナーに対して同じリージョンのエンドポイントグループを複数設定はできません）

コンソール上の操作では、エンドポイントグループを追加したいリスナーの詳細画面より、「Add endpoint group」がエンドポイントグループを追加します。

エンドポイントグループのリージョンの選択は必須で、その他設定項目を入力し次へ進みます。

作成するエンドポイントグループに追加するエンドポイントの設定画面に遷移しますので、ここでエンドポイントとして利用した既存のリソースを指定することができます。エンドポイントは後からでも追加できるので、エンドポイントのない空のエンドポイントグループを作ることもできます。

上記の作業を繰り返すことで、下記画像の様にひとつのリスナーに対して東京リージョンと大阪リージョンのエンドポイントグループをそれぞれ作成することができます。

DNS 名

Global Accelerator は作成したアクセラレータに対して静的な IP アドレスを 2つ提供しますが、合わせて DNS 名も割り当てられます。

この DNS 名を名前解決すると、アクセラレータに割り当てられている 2つの IP アドレスが返却されることも確認できます。

$ dig +short xxxxxxx.awsglobalaccelerator.com
15.xxx.xxx.x
3.xx.xxx.xxx
$

Global Accelerator が提供する DNS 名に関しては、詳細なブログがいくつかありますので、こちらをご参照ください。

関連する機能

Global Accelerator の基本的な要素について記載したので、Global Accelerator に関連する機能をいくつかピックアップしていきます。

クライアント IP アドレスの保持

Global Accelerator は以下のエンドポイントに対してクライアント IP の保持機能を提供しており、デフォルトで有効になっています。ALB の場合は、X-Forwarded-For ヘッダにクライアント IP アドレスが格納される形になります。

ALB
- Internet-facing の場合は IP アドレスの保持を選択可能
- Intenal の場合は常に IP アドレス保持
EC2

下の 2つの画像は Internet-facing ALB と Internal ALB をそれぞれ用意して Global Accelerator のエンドポイントとして指定した場合のものですが、Internet-facing の場合のみ、IP アドレスの保持機能の有効化/無効化を選択できる様になっていることがわかります。

一方で、以下のエンドポイントに対してはクライアント IP アドレスの保持機能は非対応となっており、送信元の IP アドレスは Global Accelerator のエッジロケーションの IP アドレス範囲で置き換えられます。

また、Global Accelerator はクライアント IP アドレスの保持をサポートするために、エンドポイントが存在する VPC にセキュリティグループを、エンドポイントが存在する各サブネットにネットワークインターフェース（以下 ENI）を作成します。

下記では、同一 VPC 内の異なる 2つのサブネットを指定した 2つの ALB（サブネットの合計は 4つ）をそれぞれ GlobalAccelerator のエンドポイントに指定した後にセキュリティグループと ENI を確認しています。

セキュリティグループ名が「GlobalAccelerator」のセキュリティグループがひとつ作成されている ことがわかります。インバウンドルールはなしで、画像には写っていませんがアウトバウンドは全開放となっていることも確認できます。

このセキュリティグループを他のセキュリティグループのルールで利用することで、クライアントからの通信を GlobalAccelerator 経由のみに限定したりすることができます。注意点として、GlobalAccelerator が作成するセキュリティグループを変更することは推奨されていません ので気をつけましょう。

Global Accelerator は、Elastic Network インターフェイスに関連付けられているセキュリティグループを作成します。システムによって禁止されるわけではありませんが、これらのグループのセキュリティグループ設定を編集しないでください。

参考 : Best practices for client IP address preservation - AWS Global Accelerator

ENI は ALB が利用しているサブネットの合計と同じく、4つの ENI が作成されている ことが確認できます。また、セキュリティグループとして上記で確認した GlobalAccelerator が作成したセキュリティグループがアタッチされていることもわかります。

参考 : Preserve client IP addresses in AWS Global Accelerator - AWS Global Accelerator

Global Accelerator フローログの記録

GlobalAccelerator では、フローログを有効にすることで、GlobalAccelerator と ENI 間のトラフィックに関する情報を取得 することができます。これにより、例えばエンドポイントまでトラフィックが到達しない場合のトラブルシューティングなどに役立てることが可能です。

フローログはデフォルトでは無効 になっているため、明示的に有効化する必要があります。フローログの設定状況の確認や変更は現状（2022/3）コンソールでは行えない様なので、CLI での設定が必要となります。

CloudShell でフローログの設定状態の確認と、フローログの設定を行ってみました。保存先の S3 バケットに求められるバケットポリシー等については下記参考リンク等を参照ください。（GlobalAccelerator に関する CLI 操作はオレゴンリージョンで実施する必要があります）

# フローログ設定状況の確認（false が確認できる）
$ aws globalaccelerator describe-accelerator-attributes --accelerator-arn arn:aws:globalaccelerator::000000000000:accelerator/xxxx-xxxx-xxxx-xxxx-xxxx
{
    "AcceleratorAttributes": {
        "FlowLogsEnabled": false
    }
}
$
# フローログの設定
$ aws globalaccelerator update-accelerator-attributes \
> --accelerator-arn arn:aws:globalaccelerator::000000000000:accelerator/xxxx-xxxx-xxxx-xxxx-xxxx \
> --region us-west-2 \
> --flow-logs-enabled \
> --flow-logs-s3-bucket logs-bucket-000000000000  \
> --flow-logs-s3-prefix globalaccelerator/
{
    "AcceleratorAttributes": {
        "FlowLogsEnabled": true,
        "FlowLogsS3Bucket": "logs-bucket-000000000000",
        "FlowLogsS3Prefix": "globalaccelerator/"
    }
}
$
# 再度確認（フローログが設定されていることが確認できる）
$ aws globalaccelerator describe-accelerator-attributes --accelerator-arn arn:aws:globalaccelerator::000000000000:accelerator/xxxx-xxxx-xxxx-xxxx-xxxx
{
    "AcceleratorAttributes": {
        "FlowLogsEnabled": true,
        "FlowLogsS3Bucket": "logs-bucket-000000000000",
        "FlowLogsS3Prefix": "globalaccelerator/"
    }
}
$

参考 : Flow logs in AWS Global Accelerator - AWS Global Accelerator

クライアントアフィニティ機能の利用

Global Accelerator の要素でリスナーを紹介した際に、クライアントアフィニティ という項目がありました。

Global Accelerator は、デフォルトで 5-tuple に基づいて生成されたハッシュ値やエンドポイント側のパフォーマンスを考慮し、トラフィックをルーティングします。

Global Accelerator は、5 タプルプロパティ (送信元 IP、送信元ポート、送信先 IP、送信先ポート、およびプロトコル) を使用してハッシュ値を選択します。次に、最高のパフォーマンスを提供するエンドポイントを選択します。

一方で、リスナーの設定でクライアントアフィニティを 送信元IP に設定すると、Global Accelerator は送信元 IP と宛先 IP を利用してハッシュ値を生成する様になるため、IP が変化しない限りは同じユーザからの接続を同じエンドポイントにルーティングする様な動作となります。

参考 : Client affinity - AWS Global Accelerator

トラフィックダイヤルによるトラフィックフローの調整

Global Accelerator ではひとつのリスナーに対して複数のエンドポイントグループを設定し、マルチリージョンでエンドポイントを持つことが可能ですが、トラフィックダイヤル 設定を利用することで、各エンドポイントグループに対する重みづけを行い、一部トラフィックを他リージョンにリダイレクト することが可能です。

デフォルトではすべてのエンドポイントグループのトラフィックダイヤルは 100 に設定されています。下図では東京リージョン/大阪リージョンのエンドポイントグループがあるリスナーA に紐づいている場合を想定しています。この場合、東京リージョンに近いクライアントは東京リージョンのエンドポイントグループ、大阪リージョンに近いクライアントは大阪リージョンのエンドポイントグループにトラフィックがルーティングされます。

一方で、例えば東京リージョンのエンドポイントグループのトラフィックダイヤルを 50 にした場合、トラフィックダイヤルが 100 の場合に東京リージョンのエンドポイントグループに流れるはずのトラフィックのうち、50% は他リージョンのエンドポイントグループに流れる様な動作になります。（今回は他のエンドポイントグループが大阪しかないので、大阪に流れるイメージ）

このトラフィックダイヤルの仕組みを利用することで、例えば一時的に片方のエンドポイントグループのトラフィックダイヤルを 0 にしてトラフィックが流れない様にしてメンテナンスを行うなどの活用ができます。

参考 : Adjusting traffic flow with traffic dials - AWS Global Accelerator

一方で、エンドポイントグループに正常なエンドポイントがひとつもない場合、Global Accelerator はエンドポイントグループ間のフェイルオーバーを試みます。この時、トラフィックダイヤルの設定は無視される形となるため、たとえダイヤルトラフィックが 0 であってもトラフィック送信のターゲットとなります のでご注意ください。

重みがゼロより大きいエンドポイントグループに正常なエンドポイントがない場合、Global Acceleratorは、別のエンドポイントグループの重みがゼロより大きい正常なエンドポイントにフェールオーバーしようとします。このフェイルオーバーの場合、GlobalAcceleratorはトラフィックダイヤル設定を無視します。したがって、たとえば、エンドポイントグループのトラフィックダイヤルがゼロに設定されている場合でも、グローバルアクセラレータはそのエンドポイントグループをフェールオーバーの試行に含めます。

参考 : Failover for unhealthy endpoints - AWS Global Accelerator

エンドポイントの重み付けによるトラフィックフローの調整

エンドポイントグループ内には複数のエンドポイントを設定することが可能ですが、各エンドポイントに対して 0〜255 までのウェイト値 を設定し、各エンドポイントに送信するトラフィックの割合を制御することが可能です。送信されるトラフィックの割合は、各エンドポイントに与えられたウェイト値の合計に対する自身のウェイト値の割合によって決定 されます。また、ウェイトが 0 のエンドポイントに対してはトラフィックの送信は行われません。

例えば、4つのエンドポイントがエンドポイントグループに存在し、それぞれウェイトが 150/50/200/0 だったとします。この場合、下記の計算式で送信されるトラフィックの割合を計算することができます。

ウェイト 150 のエンドポイント ... 150/(150 + 50 + 200 + 0) = 37.5%
ウェイト 50 のエンドポイント ... 50/(150 + 50 + 200 + 0) = 12.5%
ウェイト 200 のエンドポイント ... 200/(150 + 50 + 200 + 0) = 50%
ウェイト 0 のエンドポイント ... 0/(150 + 50 + 200 + 0) = 0%

例えば、ウェイトが 0 より大きいエンドポイントが全て異常なステータスであり、かつウェイトが 0 のエンドポイントが正常であった場合を考えます。この場合、ウェイトが 0 のエンドポイントにはトラフィックは送信されず、ひとつ前の「トラフィックダイヤルによるトラフィックフローの調整」に記載したエンドポイント間のフェイルオーバーが発生します。そのため、何があってもトラフィックを送信したくないエンドポイントには、トラフィックダイヤルだけでなくウェイトの設定を 0 にしておくと良さそうです。

参考 : Endpoint weights - AWS Global Accelerator

ヘルスチェック

Global Accelerator はエンドポイントに対して定期的なヘルスチェックを行い、チェックの結果正常とみなされたエンドポイントにのみトラフィックをルーティングします。Global Accelerator における ヘルスチェックの設定方法はエンドポイントの種類によって異なる ため、注意が必要です。

まず、エンドポイントが EC2 もしくは EIP の場合、Global Accelerator にて設定されたヘルスチェック が行われます。ヘルスチェックの設定先としては、エンドポイントグループに対して設定を行う様な形になります。

エンドポイントグループの編集画面にて、Configure health checks 配下の項目でヘルスチェックに関する設定を行うことができます。項目としてはポート/プロトコル/ヘルスチェック間隔/しきい値 の 4つです。

注意点としては、Global Accelerator によるヘルスチェックは TCP で行われる ため、UDP トラフィックを受けつけるエンドポイントであっても、ヘルスチェック用の TCP を処理できる様にエンドポイントを構成しておく必要があります。

UDP リスナーを持つ EC2 インスタンスまたは Elastic IP アドレスエンドポイントの場合、Global Accelerator はヘルスチェックにリスナーポートと TCP プロトコルを使用するため、エンドポイントに TCP サーバーが必要です。

一方で、エンドポイントが ALB/NLB の場合は Global Accelerator 側で設定されたヘルスチェックではなく、各エンドポイントである ALB/NLB にて設定されたヘルスチェック設定が適用 されます。ALB/NLB 側のヘルスチェック結果を Global Accelerator で参照している様なイメージになります。

参考 : Changing health check options - AWS Global Accelerator

CloudFront との使い分け

AWS のグローバルネットワークを活用したサービスとして CloudFront がありますが、Global Accelerator との使い分けについても軽く触れておきたいと思います。

AWS Summit Online Tokyo 2020 のセッション、「AWS-29 Amazon CloudFrontとAWS Global Acceleratorを使ったAWS Global Networkの活用方法」で挙げられている観点の一部は以下です。

対応するプロトコル
- CloudFront は HTTP/S
- Global Accelerator は TCP/UDP 対応
コンテンツのキャッシュレイヤー有無
- CloudFront はキャッシュ活用による、より高速なコンテンツ配信を実現
- Global Accelerator はキャッシュ機能なし
クライアントが参照する IP の数
- CloudFront は ip-ranges.json に記載の IP アドレス範囲
- Global Accelerator はアクセラレーターに対して払い出される静的な IP が 2つ
AWS サービス以外をオリジンとして指定可能か
- CloudFront は可
- Global Accelerator は現状 NLB/ALB/EC2/EIP のみ

その他、詳細については下記セッションレポートも非常に参考になりますので、こちらも合わせて参照ください。

料金

Global Accelerator の料金は、アクセラレータが存在している間発生する固定の料金 と データ転送費 の 2つが発生します。

まず、固定料金については、1時間毎に 0.025 USD となっています。これは、30日間起動し続けた場合に 18 USD が発生する計算となります。

データ転送費については、以下 2つのルールで課金が発生されます。

課金レートはトラフィックの送信元リージョンと送信先リージョンの組み合わせで決定
全てのデータ転送に対して課金されるのではなく、主要なデータ転送方向についてのみ課金が発生する

2 については少しイメージしづらいかも知れませんが（私はパッと理解できませんでした）、公式の料金ページの例では下記の様な計算が行われています。発生するデータ転送全てに課金されるわけではないという認識だけ持っておけると良いかと思います。実際にどの程度課金されるかは動かしながら確認するのが確実かと思います。

アクセラレーターを使用して AWS ネットワーク経由で転送される月間のデータ量が 10,000 GB の場合、トラフィックの 60% はアプリケーションからインターネットのユーザーへのアウトバウンドトラフィックであり、残りの 40% はインターネットのユーザーから AWS リージョンのアプリケーションへのインバウンドトラフィックです。1 時間毎に、トラフィックの主要な方向である、ユーザーへのアウトバウンドトラフィックに対してのみ課金されます。したがって、1 か月に 10,000 GB ではなく 6,000 GB 分の料金がかかります。

参考 : 料金 - AWS Global Accelerator | AWS